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8) D Claim(s) are subject to restriction and/or election requirement. 
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Art Unit: 261 1 

DETAILED ACTION 
Double Patenting 

1 . The nonstatutory double patenting rejection is based on a judicially created 
doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the 
unjustified or improper timewise extension of the "right to exclude" granted by a patent 
and to prevent possible harassment by multiple assignees. See In re Goodman, 1 1 
F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 

USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 
1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970);and, In re Thorington, 
418 F.2d 528, 163 USPQ 644 (CCPA 1969). 

A timely filed terminal disclaimer in compliance with 37 CFR 1 .321 (c) may be 
used to overcome an actual or provisional rejection based on a nonstatutory double 
patenting ground provided the conflicting application or patent is shown to be commonly 
owned with this application. See 37 CFR 1 .130(b). 

Effective January 1 , 1994, a registered attorney or agent of record may sign a 
terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 
37 CFR 3.73(b). 

2. Claims 1 -1 6 are rejected under the judicially created doctrine of obviousness- 
type double patenting as being unpatentable overclaims 1, 3, 4, 6-9, 12, 14-16 of U.S. 
Patent No. 6,636,482 to Cloonan et al. Although the conflicting claims are not identical, 
they are not patentably distinct from each other because allowing the instant application 
would result in an unwarranted time-wise extension of the monopoly granted for the 
invention defined by claim 1 of U.S. Patent 6,636,482. 

Claims 1 , 3, 9 and 1 1 of the instant application is a broader characterization of 
the already patented claims 1 and 9 respectively of U.S. Patent 6,636,482. 

Claim 2 of the instant application corresponds to patented claim 3. 

Claims 4 and 12 of the instant application uses downstream cable data system 
channels. It is well known to use downstream data system channels for the benefit of 



efficiently allocating bandwidth. 
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Claim 5 of the instant application corresponds to patented claim 4. 
Claim 6 of the instant application corresponds to patented claim 7. 
Claim 7 of the instant application corresponds to patented claim 6. 
Claim 8 of the instant application corresponds to patented claim 8. 
Claim 10 of the instant application corresponds to patented claim 1 1 . 
Claim 13 of the instant application corresponds to patented claim 12. 
Claim 14 of the instant application corresponds to patented claim 15. 
Claim 15 of the instant application corresponds to patented claim 14. 
Claim 16 of the instant application corresponds to patented claim 16. 

3. Claims 1 -1 6 are provisionally rejected under the judicially created doctrine of 
obviousness-type double patenting as being unpatentable over claiml , 2, 5-8, 10, 1 1 , 
and 14-17 of copending Application No. 09/802,092. Although the conflicting claims are 
not identical, they are not patentably distinct from each other because allowing the 
instant application would result in an unwarranted time-wise extension of the monopoly 
granted for the invention defined by claim 1 of U.S. Patent Application No. 09/802,092. 

This is a provisional obviousness-type double patenting rejection because the 
conflicting claims have not in fact been patented. 

Claims 1 and 9 of the instant application is a broader characterization of claims 1 
and 10 respectively of Patent Application No. 09/802,092. 

Claims 2 and 10 of the instant application corresponds to claims 2 and 11, 
respectively. 
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Claims 3 and 1 1 of the instant application use upstream cable data system 
channels. It is well known to use upstream data system channels for the benefit of 
efficiently allocating upstream bandwidth. 

Claims 4 and 12 of the instant application uses downstream cable data system 
channels. It is well known to use downstream data system channels for the benefit of 
efficiently allocating downstream bandwidth. 

Claims 5 and 13 of the instant application corresponds to claims 5 and 14, 
respectively. 

Claims 6 and 14 of the instant application corresponds to claims 6 and 15, 
respectively. 

Claims 7 and 15 of the instant application corresponds to claims 7 and 16, 
respectively. 

Claims 8 and 16 of the instant application corresponds to claims 8 and 17, 
respectively. 

Claim Objections 

4. Claims 1 and 9 are objected to because of the following informalities: 

Claim 1 recites the limitation "the available bandwidth" in line 3. There is 
insufficient antecedent basis for this limitation in the claim. For the rest of this office 
action, "the available bandwidth" will be interpreted as "available bandwidth." 
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Claim 1 recites the limitation "the bandwidth" in line 6. There is insufficient 
antecedent basis for this limitation in the claim. For the rest of this office action, "the 
bandwidth" will be interpreted as "a bandwidth." 

Claim 9 recites the limitation "the available bandwidth" in line 3. There is 
insufficient antecedent basis for this limitation in the claim. For the rest of this office 
action, "the available bandwidth" will be interpreted as "available bandwidth." 

Claim 9 recites the limitation "the bandwidth" in line 7. There is insufficient 
antecedent basis for this limitation in the claim. For the rest of this office action, "the 
bandwidth" will be interpreted as "a bandwidth." 

Appropriate correction is required. 

Claim Rejections - 35 USC § 102 

5. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 1 02 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by 
another filed in the United States before the invention by the applicant for patent or (2) a patent 
granted on an application for patent by another filed in the United States before the invention by the 
applicant for patent, except that an international application filed under the treaty defined in section 
351(a) shall have the effects for purposes of this subsection of an application filed in the United States 
only if the international application designated the United States and was published under Article 21(2) 
of such treaty in the English language. 

6. Claims 1 , 3, 4, 9, 1 1 , and 12 are rejected under 35 U.S.C. 102(e) as being 
anticipated by U.S. Patent 6,223,222 to Fijolek et al. (Fijolek). 

Regarding claims 1 and 9, Fijolek teaches a system and method for controlling 
traffic loading in cable modem system, comprising determining using a QoS server 
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(332) available bandwidth on a requested channel (col. 29, II. 56-59), comparing the 
bandwidth by means of the QoS server (332) on the requested channel to the 
bandwidth requested by the user (col. 33, II. 42-53), determining whether the bandwidth 
is greater than the requested amount of bandwidth (col. 33, II. 48-53), and granting the 
cable service request based upon the determination whether the bandwidth of greater 
than the bandwidth to be allocated (col. 33, II. 53-65, see also col. 33-34, II. 66-1 1). 

Regarding claims 3, 4, 1 1 , and 12, Fijolek teaches allocating services for both the 
upstream and downstream channels (col. 30, II. 19-28, see also Table 10). 

Claim Rejections - 35 USC § 103 

7. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

8. Claims 2 and 1 0 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
U.S. Patent 6,223,222 to Fijolek et al. (Fijolek) in view of U.S. Patent 6,742,187 to 
Vogel. 

Regarding claims 2 and 10, Fijolek is silent on transferring the subscriber to a 
different data channel with more available capacity when the requested channel is less 
than the bandwidth to be allocated. Vogel teaches transferring a subscriber to a 
different channel with a greater channel capacity when the available capacity on a 
channel degrades (and thereby is less than the bandwidth requested) (col. 13, II. 10-25). 
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Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Fijolek by switching to a different channel when the 
available capacity is less than the bandwidth requested as taught by Vogel in order to 
reduce delays in channels and efficiently provide dynamic load balancing in the 
upstream direction (Vogel: 3, II. 10-16). 

9. Claims 5 and 1 3 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over 
U.S. Patent 6,223,222 to Fijolek et al. (Fijolek) in view of U.S. Patent 6,850,965 to Allen. 

The examiner notes that U.S. Patent 6,850,965 is a continuation-in-part of U.S. 
Application No. 09/344,688 support for the col. 23, II. 18-57 of the patent can be found 
in application 09/344,688 (specifically on pages 1 8-20). 

Regarding claims 5 and 13, Fijolek teaches denying service if the available 
bandwidth on a requested channel is less than the bandwidth being allocated (col. 33, II. 
61-65), accordingly, Fijolek fails to teach granting service if the available bandwidth on a 
requested channel is less than the bandwidth being allocated. Allen teaches granting 
services when the bandwidth on the requested channel is less than the bandwidth being 
allocated but greater than the sums of the minimum flow rates on the channel (col. 23, 
II. 18-40). Therefore, it would have been obvious to one of .ordinary skill in the art at the 
time the invention was made to modify Fijolek by granting service if the available 
bandwidth on a requested channel is less than the bandwidth being allocated as taught 
by Allen in order to maximizing charges thereby increasing profits by using the reserve 
bandwidth (Allen: col. 23, II. 48-57). 
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10. Claims 6, 7, 14, and 15 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent 6,223,222 to Fijolek et al. (Fijolek) and U.S. Patent 
6,850,965 to Allen in view of U.S. Patent 6,097,697 to Yao et al. (Yao). 

Regarding claims 6, 7, 14, and 15, Fijolek and Allen teach allocation schemes 
but are silent on losing packets when a channel is oversubscribed and when the 
packets are randomly lost. Yao teaches in a congested network (e.g. oversubscribed) 
that it is common to randomly lost packets (col. 4, II. 20-45). Therefore, it would have 
been obvious to one of ordinary skill in the art at the time the invention was made to 
modify Fijolek and Allen by randomly losing packets in a congested network as taught 
by Yao in order to effectively adjust the transmission rates to reduce the number of lost 
packets (col. 2, II. 41-44). 

11. Claims 6, 8, 14, and 16 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over U.S. Patent 6,223,222 to Fijolek et al. (Fijolek) and U.S. Patent 
6,850,965 to Allen in view of U.S. Patent 6,345,038 to Selinger. 

Regarding claims 6, 8, 14, and 16, Fijolek and Allen teach allocation schemes 
but are silent on losing packets when a channel is oversubscribed and when the 
packets are based on levels of service, where higher levels of service lose less packets. 
Selinger teaches priority ordered queues (col. 7, II. 51-63), which give a priority to 
packets having higher levels of Quality of Service (QoS), thereby when a channel is 
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oversubscribed the higher levels of service drop less packets (col. 1, II. 49-63). 
Therefore, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify Fijolek and Allen by losing packets are based on levels of 
service, where higher levels of service lose less packets as taught by Selinger in order 
to guarantee subscribers a level of service during heavy congestion, thereby enabling 
users to pay for the type of service that they would like to receive. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Andrew Y Koenig whose telephone number is (703) 
306-0399. The examiner can normally be reached on M-Th (7:30 - 6:30). 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Christopher Grant can be reached on (703) 305-4755. The fax phone 
number for the organization where this application or proceeding is assigned is 703- 
872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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Method for Connection Acceptance Control and Optimal Multi- 
Media Content Delivery over Networks 



Cross-reference to related applications. 

This invention claims the priority date of provisional application number 60/108,777, "Method 
for Connection Acceptance Control and Optimal Multimedia Content Delivery Over 
Networks", inventor Arthur Allen , filed 1 1/17/98. 




1.1 Field of the Invention 

This invention relates to the field of delivery of multimedia content over a variety of networks. 
More specifically, it pertains to multimedia servers which service many clients simultaneously 
for the delivery of multimedia content which is used and played back at each client. It 
addresses methods for determining optimal delivery rates to each client and methods for 
determining whether new clients may be accepted without diminishing the quality of service to 
existing clients. 



1.2 Background Information 

In the history of multimedia program delivery, some in the industry have long advocated the 
use of large client-side buffers and faster-than-real-time content delivery over a network as 
offering the best of all worlds; a jitter-free viewing experience and a cost-effective utilization of 
the network resources at hand. Few systems, however, go very far in addressing how to 
schedule clients or a method for accepting new clients. Real-time systems, often known as 
streaming systems, can schedule new clients in a very simple manner — if sufficient bandwidth 
remains for the added real-time stream, then the client may be accepted. However, such 
systems do not maximize the number of simultaneous clients. On the other hand, fister than 
real-time delivery, sometimes known as store-and-forward systems, open up the possibility for 
more flexible scheduling procedures to control and optimize the number of simultaneous 
clients while ensuring a high level of quality of service. 

The methods for such call acceptance and flow modulation that have been proposed in the 
prior art have been largely ad-hoc and also incomplete. These have been ad-hoc in the sense 
that there has been no guiding rationale for their selection from among many possible and 
potentially superior alternatives. The methods have also been incomplete insofar as they did 
not address the question of whether any given incoming request for service should be accepted 
or denied. Video-on-demand systems, or more generally, any system in which a multimedia 
server is designed to serve multiple clients over a network to deliver bounded content, can 
benefit from the use of such flow modulation techniques and call acceptance procedures. 



Optimal Content Flow Modulation 

One time-honored way of designing methods of the class required here is to re-cast the 
problem to be solved as an optimization problem, in which one seeks to mfnrimiTe a designated 
value junction moment-by-moment, subject to a set of real- world operational constraints 
which will typically vary over time. Accordingly, given a set of clients and associated sessions, 
an optimal delivery procedure continuously establishes content flow rates from the content 
saver to each of its clients so as to maximize aggregate value according to the governing value 
function. 

This approach holds several advantages: 1) optimization problems are well understood, and 
are tractable by a large and diverse collection of computational methods; 2) if it exists, the 
global solution that is obtained is arguably optimal by construction, and thus superior or equal 
to all other. 

The present invention teaches the method of optimizing two particular value functions: 

1) total data delivered, (maximize throughput) 

2) total delivery charges (maximize charges). 

The first value function does not distinguish one customer from another and will deliver as 
much data as possible from server to clients irrespective of the characteristics of the latter. The 
second value function favors the service of high paying customers. It can easily be seen that 
the first function is a special case of the second one whereby all clients are charged equally. 

As will be seen in this disclosure, optimizing for these functions and identifying the necessary 
constraints requires a new and unique perspective that is specifically designed for the 
multimedia environment. Moreover, the disclosed methods are specifically designed to 
account for and accommodate real-world scenarios of today's networks. Consequently many 
variations of the method are presented to accommodate various scenarios. 




Call/Connection Acceptance Control (CAC) 

A CAC procedure is responsible for deciding whether a candidate for service can be 
accommodated without jeopardizing sessions already in progress at the presort time or at some 
time in the future; failing that h must decide whether a service request should be queued for a 
time, or rejected. 



Flow modulation 

Flow modulation methods are those portions of the system which manage the communication 
and data flow between the server and the cEents. Collectively, these methods provide the 
multimedia data to the client and provide the server with the information about the state of the 
transmission, playback, user status and network status. These parameters are further used by 
the present invention in the CAC procedures. In feet, as will be shown, the proposed CAC 
procedures are tightly integrated with the flow modulation methods. 

Adaptation to Variations in Network Capacity 

Operational constraints may change over time. For instance, one might elect to vary the total 
bandwidth available for multimedia content delivery according to the time of day. 
Alternatively, exogenous data flows on the network may cause unexpected disturbances by 
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usurping available bandwidth and impeding the delivery of data along established session 
channels. The content delivery strategy of the present invention includes the ability to adapt to 
scheduled as well as unexpected disturbances so as to minimize unwanted disruptions of 
services. 



Burst transmissions provide the opportunity to adapt 

The present invention, due to it's faster-than-realtime transmissions (also know as burst 
transmissions), which are realized by use of high-bandwidth networks and large client cache or 
intermediate storage, provides an opportunity to adapt to changing network conditions. In 
contrast real-time (streaming) systems are essentially designed for worst-case scenarios: each 
client must be assumed to constantly use the complete real-time playback bandwidth. Such a 
system is unable to adapt to any derivation from this scenario. For example, take the simple 
case where the total server bandwidth is 1 00% utilized by all clients playing back the streaming 
video. Should any network condition change, such as a temporary decrease in available 
bandwidth over the network, then one or more clients' playback is interrupted, and the system 
can not recover from such a condition until the bandwidth is regained. Even worse if a single 
client presses pause either that unused bandwidth must remain reserved and no more clients 
can be accepted, or that paused client is pushed out in order to service the new client. In 
essence little or no C AC procedure may be implemented. 

In contrast the present invention burst transmits portions of a program and immediately 'gets 
ahead of itself , thus allowing headroom for a myriad of methods to intelligently handle new 
clients, client interactivity and possible network fluctuations. 

Methods are taught for optimally determining the flow rate to each client. Methods are also 
taught for accepting or rejecting new clients; these call-acceptance methods are tightly coupled 
with said flow rate modulation methods. A series of constraint expressions are presented 
which govern the methods for determining the flow rates and acceptance of new clients. 
Linear programming techniques are used to optimally solve these expressions. Various 
embodiments are presented including scenarios for multiple-rate tariffs, and time-of-day 
bandwidth variations. 



Figure 1 depicts the flow of control and/or data between the different stations of a content 
delivery session. 

Figure 2 illustrates the Entity Data Model. 
Figure 3 geometrically illustrates the problem statement. 
Figure 4 geometrically illustrates an expansion of the problem statement 
Figure 5 illustrates a method for implementing flow modulation. 
Figure 6 illustrates a method for implementing flow modulation for maximized charges. 
Figure 7 illustrates typical content flow. 
Figure 8 illustrates typical server swing capacity. 
Figure 9 illustrates a method for call-acceptance and control (CAC). 
Figure 1 0 illustrates planned constraints on maxinuirn flow. 
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Figure 1 1 illustrates a method for call-acceptance and control (C AC) with scheduled flow 
changes 

Figure 12 illustartes stratification of services. 

Figure 13 illustrates a method for call-acceptance and control (CAC) for maximal charge. 




4.1 Data & Control Flows (Figure 1) 

Figure 1 depicts the flow of control and/or data between the different stations of a content 
delivery session. As shown a client attempts a connection (100) and manifests itself to the 
Content Selection subsystem by means of a low bandwidth control channel (not shown). Next 
the client is authenticated and a selection is made (110), typically with the aid of a browser 
software such as Netscape or Microsoft Internet Explorer. If the client is not authenticated, it 
is dismissed from the system (120). If the client has been authenticated and a program selected 
for viewing then the rate of service is set at this point (130), perhaps according to the selection 
that was made, or some contractual stipulation. The client is now placed on the service queue 
of the CAC subsystem (140). A client that is made to wait too long will eventually balk (150). 
Assuming this does not occur, the CAC subsystem will eventually allocate a channel to the 
client and open a session (160). Control now devolves upon the Content Flow Modulator (not 
shown) which starts the flow of content from server to client (170). Subsequent capacity 
charges, whether predictable or not, may force an abrupt termination of a session in progress 
(180). Otherwise the session runs to completion (190). 

4.2 Entity Data Model (Figure 2, listing, table) 

The entities entering into our discussion are depicted in figure 2. Client 200 mflint nmq certain 
data associated with this entity; as shown but not labeled, which includes without limitation, 
status, id and costOfService. The other entities also each include unlabeled but depicted data. 
The diagram further depicts the relationship between each entity. As shown, client 200 is 
assigned a session 240. Client 200 employs a channel 210. Client 200 selects contentSelection 
230. Session 240 delivers content through channel 210. Server 220 modulates channel 210. 
Server 200 contains contentSelection 210. Server 220 accepts, defers or denies client 200. And 
contentSelection 230 is associated with session 240. 

Furthermore the figure depicts the various one-to-many relationships. Each client 200 employs 
one channel 210. Client 200 may or may hot receive one of channel 210, as depicted by the 0/1 
notatioa Similarly, client 200 may or may not receive a session 240. However, whenever clint 
200 does receive a session 240, it will always receive a channel 2 1 0 since channel 2 1 0 and 
session 240 are allocated as a pair. One or more (N) of client 200 may select one of 
contentSelection 230. And server 220 contains one or more (N) of contentSelection 230. Each 
one of contentSelection 230 is associated with 0-N of session 240. Each session 240 delivers 
content through one of channel 210. And server 220 modulates one or more (N) of channel 
210. 



A more detailed list of each entity of figure 2, and each one's associated description, data 
dements and function calls is listed below. This listing closely resembles that of object-oriented 
programming. As such, 'methods' represent the ability to obtain or modify data, while 
'attributes' represent data which is directly associated with that particular entity. The listing 
also includes information relating to one embodiment wherein software programming specifics 
are disclosed, such as a variable type (double, int and so forth) and more. The present 
invention is not limited to such an embodiment and other implementations are possible without 
deviating from the scope and intent of the present invention. The listing, however detailed, is 
merely illustrative of the data and functions which are used in the equations and methods 
described herein. 

Consequently, data and functions from this listing, associated with the various entities, will be 
used in forthcoming equations, flowcharts and methods. The reader is directed to this listing as 
reference when reading such equations and examining such drawings. 

start of entity data model detailed listing — 

Model: Untitled 1 (public) 

Contains: 

client, session, channel, server, contcntSelection. 

Component: client (public Class/Interface) 

Comment 

A client entity stands for a client presently requesting or receiving service. 

Methods: 

public static lookup (id: in int) : client 
public Getld 0 : const int& 
public Setld (val : in int&) 
public GetCostOfService 0 : const doubled 
public SetCostCHServke (val : in doubled) 
Attributes: 

private status: dient<int> 

Specifies whether or not a client has been allocated a channel and session, 
private id: int 

Integer-valued identifier that is unique to the client (primary key). Can be obtained from a monotonically 
increasing counter. 

private costOfService: double 

Dollar charge per Mbyte. This value is die same for all customers under flow optimization. Under 
cost/charge optimization may be an integer value reflective of the rank; the higher the rank the higher the 
charge. 

Has: 

public selected: conteatSdection 
public assigned a; session 

public employs: channel w r , , 

Component: session (public Class/Interface) 

Comment. 

A session entity holds various state information about the service being received by an associated customer. 
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public GetGirrentPoshion 0 : const doubled 
public SetCurrentPosition (val t in doubled) 
public GetPayloadToGo 0 : const doubled 
public SetPayloadToGo (val : in doubled) 
public GetStatus 0 : const int& 
public SetStatus (val : in int&) 
public GetMmimumFlowRate 0 : const doubled 
public SetMmimnmFlowRate (val : in doubled) 
public GetFiowRateRange 0 • const doubleA 
public SetFlowRateRange (val : in doubled) 
public GetMazFlowRate 0 : const doubled 
public SetMaxFIowRate (val : in doubled) 
Attributes: 

private playTimeToGo: double 

Indicates the minutes remaining in the viewing experience. Initialized to contentSelcctiontplayTinie (see 
below). 

private currentPosition: double 

Points into media content from which content is being delivered, 
private payloadToGo: double 

The amount of media content (in Mbytes) as yet undelivered by the server. Does not include any content 
presently stored in the client-side buffo-.. 

private status: int 

Indicates whether sesion is active or paused, 
private mmimnmFlowRate: double 

This is the rnmrmum flow from server to client required to ensure uninterrupted service over the remaining 
playTime. Has a value of zero ifplayloadToGo is zero. Given by (payloadToGo * S)/(playTimeToGo *60) 

private flowRateRange: double 

Specifies the effective range over which die channel content flow serving a session is constained without 
consideration fear interactions with other flows. Equals maxFlowRatc - minimumFlowRate 

private maxFlowRate: double 

Effective maximum bound on flow as expressed in formula (8) which must be re-evahiated periodically. 

Has: 

public delivers content through; channel 

Component: channel (public Class/Interface) 

Comment. 

A channel represents the network resources from server to client associated with an ongoing session, 
encompassing the client-side buffer if any, and its level. 

public GetBufferLevd 0 : const doub*e& 

public SetBufferLeveJ (val : in doubled) 

public GetFlowRate 0 : const doubled 

public SetFlowRate (val : in doubled) 

public GetMaxFlowRate 0 : const doubled 
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public SetMaxFlowRate (val ; in doubled) 

Attributes: 



private bufferSize: double 

Capacity of the client-side buffer (or equivalent) 

private bufferLevel: double 

Current buffer level in MBytes of stored content 

private flowRate: double 

Flow rate through channel specified by the relevant optimizing flow modulator, 
private maxFIowRate: doable 

This value represents the maximum possible flow rate from the server to an invidual client over its" 
channel". This value reflects restrictions cm flow that pertain to an individual client It may be determined 
by factors such as the bandwidth of client's link to the network, or a limit imposed administratively to 
ensure balanced network utilization.. 

Component server (public Class/Interface) 

Comment 

Entity representing the media server and its C AC and flow modulation activities, 
public GetFlowRate 0 : const doubled 
public SetFlowRate (val : in doubled) 
public GetMaxMinFlowRateQ 0 • const doubled 
public SetMaxMinFlowRateD (val : in doubled) 
Attributes: 

private maxFIowRate: double 

Maximum possible content flow that is allocated to the servo" by the network 
private flowRate: double 

Aggregate oontent flow rate, summed over all sessions and their associated channels, 
private cac_flowSafetyMargin: double 

Tunable safety margin used by the CAC algorithm to protect sessions-in-progress from being affected by 
changes in available network bandwidth. 

private maxMinFIowRateQ: double 

Applies when N rate tariffs exist This array holds the maximum floor level for each category of service. 
The value for the costiest category N is stored in maxMinFlowRate[N-l], and for the least costliest in 
maxMinFlowRate[0]. It is the relative mflgnftuHft of these ascending values that matters, not their absolute 
value. Thus the actual maximum floor flow rate for category k is given by 
server.rnaxFiowRate * (server jnaxMuiFlowRate[k- 1] /server.maxMinFlowRate[N-l]). Similarly, the 
maximum floor flow rate for category N is server.rnaxFiowRate. 

Has: 

public contains: contentSelection 
public modulates: channel 

Component: contentSelection (public Class/Interface) 

Comment. 

Entity represents a video/sound clip or other bounded unit of content A continuous data feed does not 
qualify. 

Attributes: 

private averagePlayRate: double 



The average rate at which media content is consumed by the client, as computed by dividing the (payload ♦ 
8)bythe(playTime*60) 

private playTime: double 
Duration of play of the media content in minutes. 

private payLoad: double 

total size of the content in Mbytes. 

Has: 

public is associated with: session 



end of entity data model detailed listing — 

The following table summarizes the highlights of the previous detailed description of each entity in 
Figure 2. 

Description 

Each client is denoted by an associated unique integer index u . The set 
of active clients is denoted by Saoms^ The set of deferred clients is 
denoted by Sg^se**. Incoming clients are expected to select the 
content they wish to view prior to being queued for dispatch by the 
CAC sub-system, which requires knowledge of the client's bandwidth 
requirements, duration of play, and cost of service, all of which may 
vary according to the selection. 

Servers sit astride a network and can deliver media content through the 
network to their clients up to a designated mftvinwrn flow rate. The 
server is responsible for accepting or rejecting clients, launching 
sessions and associated channels for the former, and modulates content 
flows over all channels in an optimal manner. 

A channel represents the data path between the server and the client. 
The channel buffer is typically located near or within the clients 
viewing station. The flow of content through the channel is set by the 
flow modulator sub-system. 

contentSelection A server will typically act as a repository for media content, which it 
230 can deliver to clients upon demand. For our purposes media content is 

characterized by its payload and the play duration, which together 
imply the averagePlayRate = (payload*8)/(playTime *60), The 
averagePlayRate is none other than the streaming rate imposed by real- 
time just-in-time streaming algorithms. 

session 240 Every session represents an instance of media content delivery to an 

associated client over a designated channel. The playHmeToGo 
indicates the time remaining before the content is fully played out to 
the client. The payloadToGo is the amount of content data as yet 
undelivered to the channel. A session terminates when this value 
reaches zero, at which time playTimeToGo may still be large, 
according to the capacity, the level of the channel buffer, and the 
media play rate. 



Entity 

client 200 



server 220 
channel 210 



Constraints On Content Flow 

Before moving on to more figures, it is imperative to establish some formulas and problem 
statements which are used in the methods which follow. 

The flow of content between entities is subject to the following constraints at all times. Buffer 
levels are always expressed in Mbytes and data rates in Mbhs/sec. 

(1) £ u SftctfvcCBato (clientJookup(i).channel.flowRate) <= server. maxFlowRat e 

The mm of aB channel flam cannot exceed the imposed maximum throughput 
capacity of the server. 

(2) client.lookup(i).channel.flowRate <= cKentJookup(i)xhannel.maxFlowRate 

for all 1 E SaettveClleiita 

The data path from server to client is subject to its own constriction, 

(3) client.lookup(i).channel.flowRate <= 

(dient.lookupCO*<Aannel.bu£Fa-Size- c!ientloofcup(i).channel.buflFerLevel )* 8/60 
+ 

client.lookupCO.session.mediaContent.averagePlayRate, 

for all ieSacdveCUeitta, 

The channel buffer is never allowed to overflow. 

(4) client.lookup(i).channel.flowRate <- client.lookupCi) sesaoapayloadToGo * 8/60 

for all i 6 SacttvsCBente, 

Content that does not exist can not be delivered. (Constraint 1 will ordinarily prevail 
except at the very end of a session.) 

The constraints listed above are straightforward applications of common sense in relation to 
the flow of data through constricted channels, out of finite data sources, and into and out of 
bounded buffers. By contrast, the following constraint, which imposes a miniymtm channel flow 
rate instead of a maximum, is less obvious. Indeed its introduction here and subsequent use in 
the C AC procedure constitute the central innovation of the methods presented in this 
document. The minimum value, termed the minFlowRate is set to the flow rate which, If 
sustained over the balance of the play time to go (playTimeToGo), ensures that all required 
content will be available when needed -- and no sooner - until all content is played out This 
floor value can be calculated for i e S^Kta* by the formula 

(5) dientlookupCO-session minFlowRate » (dient.lookupCO.session.payloadToGo * 8) / 
(cli«it.lookupfi).session.playTimeToGo * 60) 



Thus: 

(6) ctienUoohipCO-channel.flow 

for all I E SactfreCBcnto 

The variable constraint bounds (i.e, the values to the right of the inequality symbol) of 
equations 1-4 and 6 are re-evaluated on a periodic basis (e.g. once per second) prior to the 
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execution of the CAC procedure and optimizer. In particular, the ndnFlowRate value starts 
out at the beginning of a session equal to the streaming rate. By construction the ndnFlowRate 
rate never exceeds this initial value so long as constraint 6 is honored. In feet, constraint 5 
implies that the ndnflowRate value must be a diminishing function of time that may hold its 
value for a time but never rises. As seen from equation 6, the actual data rate of the channel, 
flowRate, is always greater than or equal to the ndnFlowRate. By design, and virtue of the 
feet the present invention uses faster-than-realtime transmissions, the system quickly gets 
ahead of itself and ensures that after initial conditions, the ndnFlowRate is always equal to or 
less than the real-time rate and that it continues to decrease. As we shall see the CAC 
procedure exploits this monotomc characteristic of the minimum flow rate over time. 

Constraints 2, 3 and 4 are of like kind, each specifying an upper bound on individual channel 
flows. Whereas the bound for constraint 2 is typically a constant, the bounds on 3 and 4 will 
vary over time. Nevertheless, only one of the three bounds is effective at any given time, 
namely the one with the smallest bound value, given by: 

(7) client.lookupO).sessioamaxFlowRate - minimum of 

1) client.lookup(i).channel.maxFlowRate, 

^ 2) (client.lookupO).channel.bufferSize - 

□ cfientlookupCO.cham^ )* 8/60 + 

-0 cKent.lcK>kupCi).sessioam^ 

w 

; <P 3) client.lookupO).session.payloadToGo * 8/60 

a • 

ffi Consequently, formulas 2, 3, and 4 can be consolidated into a single constraint, the bound for 

i*g which is computed at every scan to be the smallest bound of associated constraints 2, 3 and 4. 

(8) client.lookupCO.channel.flowRate <= client.lookup(i).session.maxFlowRate, 
'g* whereby for all ie S^eOtento.niaxflowRate is given by equation (7). 



At any one time, individual channel flows are constrained over a range, as follows: 

(9) ciient.lookup(i).sessioaflowRateRange = 

client.lookupO)sessioamaxFlowRate - cfient.lookup(i).sesaon.minimumFlowRate 

4.3.1 Value Functions 

The value functions introduced in section 1.2 can now be expressed mathematically a s linear 
functions of channel flows, as follows: 

4.3.1 Optimizing Throughput (Maximal Flow) 

(10) value = 2 icsoctivecscnto client.lookupCO channel.flowRate) 

4.3.2 Optimizing Charges (Maximal Charges) 

(1 1) value = 2 1 8 stefeecseat* (chenUookup(i)xhanne!.flowRate * 
client lookupfi).costOfiService) 
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.3 Optimization Problem Statement (Figure 3) 

The optimization problem, which in one embodiment is strictly throughput and in another case 
is charge, can be stated simply as follows: 

Find values for 

dient.lookup(i).channel.flowRate for all i e Sac^edfe,,* 

constrained by inequalities 1 through 5, such that the value obtained by evaluating expression 
10 or 1 1 assumes a maximum. 

Both of these problem formulations are examples of Linear Programming for which a number 
of well-known and generally effective computational solutions exist. In linear programming 
one seeks to optimize a linear cost fi mcflon of variables 

02) c*x =Ci*Xj + ,.„+c n »x n 

subject to a set of linear ineq uality constraints 
(13) A*x<=b 

where x r = (x u xj f c - (c u ... ,c^) are the state variable & cost vectors, A is an n-by-m 
matrix,b = (bb...l^ fa the constraim vector, and the op^ator'*' stands for matrix or scalar 
multiplication. 

Figure 3 is introduced as illustrative of the problem statement and the general methods of the 
prior art, and is not incorporated as an element of the invention. 

The linear programming problem as well as its solution can best be understood with the aid of 
geometry. Figure 3, depicting a 2-dimensional Cartesian problem space, inequality constraints 
(13) define a convex hull H 3 10 over which a search for an optimum value of x = (x If x 2 ) is 
permitted to range. The cost vector c 350 defines an infinite family of equal cost lines (hyper- 
planes) which lie orthogonal to c. Three examples of such lines are shown in U 360, Lj 365, 
and L3 370., each of progressively higher value. The supreme value of the cost function is 
obtained by sliding along c 3 50 till one can go no further, in this instance toward vertex V 4 340 
of hull H 310. Many well-known methods (e.g. the Simplex Method) work roughly in this 
feshion, exploiting the feet that at least one optimum point must be at a vertex. In particular, 
the Simplex method algorithm begins by finding a vertex (e.g. V 2 320), and then moves along 
a sequence of vertices (e.g. V 3 330, V 4 340) improving itself each time until no further 
improvement is possible & the summit is reached. 

Let us suppose instead that V 3 330 were placed along L3 370 along with V 4 340. According to 
prior art methods, V 3 330 and V 4 340 are the two possible solutions, but the equally valuable 
points in between them are not. As we shall soon see, the problem of throughput optimization 
(6) falls in this category. 

While vertex Vi 300 does not fector into this description, it is depicted in figure 3 for 
completeness. 



Flow Modulation 

A Method for Maxima! Row 

The following sections detail one embodiment to meet object 1 of section 1 .3, namely to 
optimize the total data flow. 
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4.4.1.1 Overview (Figure 4) 

Figure 4 depicts a scenario involving two flows. The convex bull is in this instance bounded by 
line segments LI, L2, L3, L4 and L5. L6 is a boundary used in a different embodiment, 
however the present embodiment uses L5 and not L6. Flow f 2 can range over the interval 
separating line segments LI from L3, namely fz*^ and f 2 MAX ; the range is depicted as f 2 RAN0£ . 
Flow fi can range over the interval between lines L2 and L4, namely fi* 40 * and f'i MAX , and 
depicted as fi 0E . The sum of flows ft and f 2 is constrained to lie inside of fine segment L5 
which, by construction, is always orthogonal to the cost vector C f . Cost vector C« is also 
illustrated but used in a distinct embodiment. In the present embodiment, only Q is used. In the 
illustrated example of the present embodiment the constraint on total flow is set to 5, and is 
therefore low enough to cause LS to intersect L3 and L4. This would not have been true had 
the value chosen had been 1 0 instead of 5. With L5 safely out of contention, the convex hull 
would instead be a simple rectangle bounded by LI through L4, thereby permitting both flows 
to assume their respective maxima without interference. In practice operational constraints 
exist intrinsically or are imposed from the outside so as to ensure cost effective sharing of 
potentially costly network resources. 

Supposing figure 4 to be correct, the well-known methods would select would vertex V3.5, 
which lies at the intersection of L3 and L5, or which lies at the intersection of L4 and L5. 
These solutions, though optimal, are undesirable for the present invention as they fail to spread 
available bandwidth over all channels as fairly as would a centrally located interior point of L5. 
For this reason a simple optimization method is taught, which is adapted to the particular needs 
of this problem and ensures a fairer allocation of constrained bandwidth among all channels. 



4.4.1 .2 Procedure (Figure 5) 

In order to optimize use of all available bandwidth, the following general method is used, with 
the details illustrated in figure 5 This method is a solution for the problem illustrated in Figure 
4, which geometrically illustrates the optimization problem in the limited case of two flows, fl 
and £2. The following description expands the problem to an arbitrary number of clients (and 
therefore flows) and presents a method for solving this optimization problem. 

Referring to figure 5, in step 500 values are calculated for the session maxFlowRate and 
sessio/LminFlowRate for each client as per the minimum and maximum constraint bound 
expressions in 6 and 8 , respectively. 

The difference between these two yields the sessionJlowRateRange of each client. Thus 

session. flawRateRange = session maxFlowRate- session. minimumFlawRate 

In step 505, the active clients are sorted in an ascending fashion based upon their 
sessioiuflowRateRange. As will be shown this critical step facilitates allocation of the 
remaining server bandwidth as evenly as possible among all active channels, thus maximizing 
the number of channels that benefit by use of the total server bandwidth. An arbitrary 
assignation of remaining bandwidth is likely to saturate the server before all channel s have been 
assigned extra bandwidth, thereby favoring certain channels on an ad-hoc bass. 

In step 5 10, each client's channel flow rate is set to the session mimimumFlowRate 

By doing so it is ensured that the minimum flow constraint is met for each session and that the 
minimum flow rate is a non-increasing function of time, which is critical to the proper 
functioning of the C AC procedure. All clients are marked as unprocessed. 

In the next step, 520, server.flowRate is set to the sum of each active client's 
session. flowRate. 
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Next, the following is iterated over all clients in sorted sequence (during any given iteration the 
selected client is given by Hs id) by performing steps 530 through 570. In step 530 evaluating 
the following expressions test for possible server saturation: 

delta = (server.maxFlowRate - server.flowRate) / (qty of unprocessed clients) 
range = client.lookup(«/).sessioiimaxFlowRate - clientlookup(W)sessioaflowRate 

If range is greater then delta, this implies that the server can be saturated in this iteration by 
allocating delta to all unprocessed clients (step 540). 

On the other hand, the * no ' path for step 530 implies that the server is not saturated and that 
the present client (given by id) will saturate first Accordingly, in 550 the delta variable is set 
as follows: 

deha = range 

Next, the flow rate is incremented for all unprocessed clients by deha, causing client id to 
saturate. 

In step 560 the server flow rate is adjusted accordingly; 

server.flowRate = server.flowRate + delta * (qty of unprocessed clients) 
In step 570 the client given by id, now saturated, is marked as processed. 



4.4.2 A Method for Maximal Charge 

The following sections detail one embodiment to meet object 2 of section 1.2, namely to 
optimize the total monetary charges within the system 

4.4.2.1 Overview (Figure 4) 

Referring back to Figure 4, cost vector C c lies orthogonal to line L6, which intersects the 
convex hull at the vertex formed by the intersection of lines L4 and L5, namely V4.5. This cost 
vector, and the optimal point that it implies, favors flow fl over flow £2 .In this example, this 
is as H should be, as the cost of service for fl equals 2, thus exceeding the cost of service of 1 
set for £2 . As the number of flows grows to exceed the number of distinct categories of 
service (and associated costs of service) the unique optimal solution, depicted in figure 4 for 
the case where every flow has a distinct cost of service, no longer applies. Once again a 
plurality of flows within a service category vie for bandwidth which a method should endeavor 
to distribute evenly. . This method is derived from the previous one, and optimizes one cost 
category after another, starting with the most costly and ending with the least costly, or when 
all available capacity is allocated. 

4.4.2.2 Procedure (Figure 6) 

Let the service categories be denoted by k= 1..N, where k also denotes the cost of service. 

Let Ci C N be the partition of Sateen** that places all clients with cost of service k in set C k . 
Partition sets C k can be ordered to form sequence SeqC = C N .Ci. 
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Figure 6 depicts the method for implementing the method to maximize the cost of service 
(service charge) according to objective function 2 in section 1 .3. 

This method is nearly identical to die previous one. The principle difference stems from the 
partitioning of clients according to their category (cost) of service: clients charged most are 
allocated bandwidth preferentially. This is accomplished by adding another level of iteration 
around the method of figure 5. The inner iteration (steps 650 through 680) functions exactly as 
before, with the difference that its actions are limited to the clients belonging to the given 
service category k (i.e. This difference also holds true of step 640 which sorts category k 
clients according to their flow ranges prior to entry in the bandwidth-allocating inner loop. The 
outer loop proceeds down a sorted sequence of service categories SeqC (generated in step 
630), starting with the category generating the greatest revenue to the service provider. Given 
a fairly static set of service categories, this sort need be performed only when the categories 
undergo change. Steps 670, 675 and 680 are identical to their counterparts in the method of 
figure 5 (i.e. 570, 575 and 580). 

The net effect of this method is preferential allocation of bandwidth according to category of 
service, and equitable treatment of clients within the same category of service. 



4.S Call Acceptance Control (CAC) 

4.5.1 CAC for Maximal Flow 

4.5.11 Overview (Figures 7-8) 

The CAC procedure applicable to this flow optimization relies on the essential step of 
accepting a new client if and only if the added load induced thereby does not compromise 
service to existing clients or the new one. This critical step could not be accomplished without 
the close integration with previously- described flow-modulation methods of figures five and 
six. 

According to the previous discussion, the minimum flow rate is the minimum sustained flow 
rate that guarantees that the associated viewer will not be subject to interruptions in service 
due to a shortfall of content from the media server. It follows that whenever data is being 
delivered at a rate in excess of the minimum flow rate, a downward adjustment toward the 
minimum level could be accommodated as needed to surrender bandwidth to any newcomer. 

Figure 7 depicts content flow over a channel over the course of a typical session, and also how 
data is delivered under real-time streaming (D). The amount of content delivered is the same 
in either case, but the manner of delivery differs considerably. A session is launched at time 0 
as the network is lightly loaded, and the optimizer sets an accordingly high flow rate. Another 
client emerges at the end of interval 700, causing a downward adjustment to the flow rate over 
interval B, as available bandwidth is shared between two sessions. During both of these 
intervals the minimum flow rote 720 drops quickly, as data accumulates in the client's media 
buffers. At the end of interval B a massive influx of clients necessitates that flow be dropped to 
the minimum flow rate, which now lies substantially below the streaming rate D and is held 
until all data is delivered at the end of interval C. Note that the minimum flow rate, graphed as 
demon 720, diminishes monotonicaliy over time. 

The server swing capacity is defined as the difference between the maximum capacity of the 
server and the total minimum flow rates for all active clients. Therefore: 



nam 14 of 37 



(14) swingCapacity = 

server.maxFlowRate - £ l8 SMttnCHatt (clientJookup(i).session.minFlowRate) 

Given the monotonia decreasing nature of gftsgirm mmitmim flnw ryt^ semr swing c apatity 

can readily be seen to be a monotomc increasing function of time over the intervals separating 
client admissions, at which points it undergoes a drop as a new load is taken on . This all- 
important characteristic implies the following: 

Any client admitted far service based on the present value of 
swing capacity is guaranteed to have sufficient bandwidth at 
its disposal over the entire future course of the session. 

Figure 8 depicts the server swing capacity 800 over the course of the sessions illustrated in 
figure 7. Swing capacity rises quickly over intervals A & B as data is delivered at high flow 
rates over the network. It holds steady over interval C when all channels flow at their minimum 
rate then jumps at the end of C before resuming its monotonic rise once again. 

4.5. 1 .2 Procedure (Figure 9) 

In this procedure, which executes on a periodic basis, queued clients awaiting bandwidth are 
scanned in FIFO order. For each one the required bandwidth is computed as per the client's 
prior content selection. If the available swing capacity reduced by a safety margin exceeds the 
amount required then the client is activated, and swing capacity is adjusted accordingly. 
Otherwise two possible cases are considered: 1) under the FirstFit embodiment the procedure 
continues scanning clients to the end of the queue, activating clients whose requirements can 
be met; 2) under the FIFO embodiment, the procedure ends with the first candidate client 
whose requirements cannot be met. 

In step 900 available server swing capacity is evaluated according to the formula 
swingCapacity = 

server.maxFlowRate - Z t B aacttvccsmts (cfient.getQ.session.minimumFlowRate) 
The bandwidth requirement for client id in Step 920 is obtained as follows: 

requiredjhandwidth = cftem Jookiip(jtf). contentSdection . averagePlayRate 
The predicate evaluated in Step 940 is given by the expression 

(requiredjbandwidth <= swingCapacity - sewer.cac JlowSafetyMargin) 

In step 950, client activation entails allocation of a session and a channel, and insertion in the 
set of active clients eligible for bandwidth allocation by the optimal flow modulator. 

In step 960 the swing capacity is diminished by the amount reserved for the activated client: 

swingCapacity = swingCapacity - requiredjbandwidth; 

4.5.2 Responding to Variations in Network Capacity (Maximal Ftow) 

In the CAC procedure for maximal flow (section 3.5. 1), a safety margin was introduced, 
namely server. cac JlowSqfetyMargin, to provide the means for ensuring that the server's 
swing capacity wQl never fell below a minimal threshold value. 



According to this procedure, the following inequality always holds true: 
(15) swingCapacity >= server. cac JlowSafetyMargin 

In the previous discussion a server' s swing capacity provided the baas for determining whether 
or not a prospective client should be allocated bandwidth. In another embodiment, server 
swing capacity can also be interpreted as specifying the maximum amount by which the 
server. maxFlowRate constraint can be dropped without affecting service, should such an 
adjustment prove necessary due, for instance; to an influx of exogenous network traffic that 
diminishes the amount available for multi-media services. Parameter 
server.cac JlowSafetyMargin can thus be set so as to guarantee a minimum opacity to 
tighten the constraint on maximum server flow in response to unexpected load changes that 
affect the server's ability to service its existing clients as well as new ones. 

4.5.3 Anticipating Scheduled Variations in Network Capacity (Maximal Flow) 

4.5.3.1 Overview (Figure 10) 

Figure 1 0 depicts how the constraint on maximum flow might be allowed to vary according to 
the time of day, day of the week, and so forth, in expectation of time- varying traffic flow levels 
extrapolated from past experience, traffic flow models, etc. Maximum flow rate 1000 can be 
seen to vary based upon the time of day. In practice, defining the right-hand-side of inequality 
constraint 1 as a time-dependent expression can impose sue* time-varying capacities. 
According to the previous description, the optimizer, which executes on a periodic baas, will 
automatically seek new flow levels for every active session as the constraint varies. There is, 
however, no guarantee that an acceptable operating point will be found for all sessions (Le. one 
that respects the minimal and maximum constraints on session channel flow). One such 
example is the case where the server is loaded to the limit and total capacity is curtailed in 
excess of the aforementioned safety margin. Should sue* a situation arise the only recourse 
may well be the termination of a number of established sessions (i.e. load shedding). 

The goal is to eliminate service disruptions of this sort by allowing the CAC procedure to look 
ahead into the future, and accept new clients only if these can be accommodated without any 
compromise in service in the midst of previously anticipated changes in available network 
capacity. The following CAC procedure generalizes the previous one: before accepting a client 
the test on swing capacity is repeated over a sequence of time segments that cover the 
proposed viewing period. 

4.5.3.2 Definitions 

Let 

(16) tjendfi) = cUent.lookup(i).session.playTimeToGo + t_now 

Let server.maxFlowRate(t) be server flow capacity as a function of time, as exemplified in 
figure 10. 

Let Seqx(t_now) = advancing sequence of future times, lead by t_now, when 
server.maxFlowRate(t) undergoes a step change. For instance, at 9: 15 in figure 10 this 
sequence reads as follows: 9:15, 9:30, 11:30, 13:30, 6:30, 7:30. 

The saver swing capacity at a future time t is computed according to the capacity and worst- 
case client flows at time t. 
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(17) swingCapacity(t) = server.maxFlowRate(t) - 

£ t_«do)>t (cBentlookupCO-^on.niinFIowRate) 

It is noteworthy that the worst-case client flows at time t are expressed in terms of the 
present t™™™»™ flow rates, which cannot increase over time, but might hold steady. Finally, a 
predicate is defined that tests whether a prospective customer will cause swing capacity to be 
exceeded at some time t, as follows: 

(18) boolean client Jits(i ,t) { 

if(client.lookup(i).contentSelection.averagePlayRate <= 

swingCapachy(t) - server.cac^flowSafetyMargin) 

return true; 
else return false; 

} 

.3 Procedure (Figure 11) 

This procedure is an adaptation of the first, which has been extended to consider swing 
capacity at times in the fixture when capacity undergoes scheduled changes. Before accepting a 
client, its minimal bandwidth requirement (which by construction of the flow modulator will 
never increase over time) is checked against projected swing capacity at points in time when 
total available capacity undergoes scheduled step changes, provided these times fell within the 
proposed content viewing period. A candidate is activated only if all tests succeed. 

Step 1 100 builds a sequence of time values (SeqT) at which step capacity changes are 
scheduled to occur. The first element of this sequence is t_now, representing the present. 

Beyond step 1 100 the queue of waiting clients is scanned in FIFO order, yielding a candidate 
designated by id at each iteration. 

The bandwidth requirement for client id in Step 1 120 is obtained as follows: 

requiredjbandwidth = cUeatlookup(«f|.contentSelection.averagePlayRate 

The worst-case eM time for content flow to id is obtained according to the content selected, 
as follows: 

t_end = tjiow + chentlookup(ia).selected.playTime 

Steps 1130 through 1 1 50 are executed within an iteration for each time point t in SeqT felling 
between t_now and t_end. This iteration is ended in step 1130 if t exceeds the time window of 
interest, or in step 1150 if the supply of scheduled capacity changes is exhausted. 

For each time value step 1 140 compares required bandwidth to projected swing capacity. 
Projected swing capacity at time t is: 

swingCapacity(t) = server. maxFlowRate(t) - 

S t_eHico > t (client.getQ).session.minimumFlowRate) 
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Note that only active clients whose t_end times occur after t are considered in the sum of 
minimum flow rates. 

The predicate expression used in step 1140 at timet is thus 

(required J>andwidth <= swingCapacity(t) - server.cac JlowSafetyMargin) 
Step 1 160 performs the same actions as step 660 in the previous cac flowchart 

The first CAC process presented in section 4.5. 1 is a special case of the presePnt one, in which 
the set of step change times to server.maxFlowRate is empty fi e. server. maxFlowRate is 
constant), and Seq^t jiow) = tjnow. 

In preparing Seq^t .now), one need only consider firture times that will pass before the longest 
possible content is played out if started at tjiow. In order to sidestep problems associated with 
rollover (at midnight, year 2000, etc.), time is best expressed as a monotonically increasing 
value (e.g. seconds since Jan 1 1990). 

4.5.3 CAC for Maximal Charges 

4.5.3.1 Overview (Figure 13) 

In section 4.4.2 a method for flow modulation was presented that maximizes charges to clients 
with active sessions. The CAC embodiments presented previously is not sufficient as it does 
not consider the cost of service as a basis for connection acceptance. As a result it may turn 
away higher paying customers while granting service to lower paying ones, thereby defeating 
the purpose for this particular embodiment. Therefore, in another embodiment is defined which 
offers the following features: 

1 . Awaiting clients are serviced in order of their respective service categories, 
higher paying clients first. 

2. Once accepted, a client is guaranteed to receive acceptable service 
irrespective of its service category. 

3. Under heavy load conditions higher paying customers are more likely to be 
accepted than lower paying ones. 

4. Lower paying customers will no be starved for service when higher paying 
ones enjoy a surplus. 

5. Available bandwidth is not thrown away needlessly while clients are being 
denied service. 

The first objective is easily met by dividing the client queue into as many bands as there are 
service categories, resulting in a banded queue. Bands are ordered within the queue according 
to their service categories, with the costliest category in front As prospective clients arrive and 
make their selection they are placed in their respective queue band according to their service 
category (which may be set contractually, according to content selection, etc.). 

Our second objective is met by employing an procedure patterned after those presented 
previously & offering the same guarantee. Toward our third an fourth objectives we propose 
dividing total available bandwidth in as many strata as there are service categories, as depicted 
in Figure 1 2 Two service categories are shown, Premium and Basic, each entailing an 
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associated cost of service. A prospective client is accepted only if there is sufficient swing 
capacity available within its service category. The swing capacity for a given category is given 
by the smaller of 1 ) the difference between its maximum floor flow rate - corresponding to the 
top of the stratum for the service category - and the sum of the minimum rates of all active 
sessions in Hs category or below, and 2) available swing capacity overall. Finally, our fifth 
objective is met by allowing the flow optimizer to function freely subject to hs operational 
constraints. The imposed ceilings on call acceptance by category relate to minimum flaw rates, 
which merely impose a floor on actual flow rates. For example, basic clients might well 
consume all available bandwidth (300) in the absence of any premium customers, yet could be 
throttled back toward their floor flow rates (which together cannot exceed 200 in this example) 
at any time should any premium customer suddenly demand service. In contrast, premium 
customers could consume the entire 300 bandwidth. As lower paying customers appear these 
would be admitted to the degree that their quota on minimum flow is not exceeded (i.e. 200) 
and the availability of swing capacity on the system 

4.5.3.2 Procedure (Figure 13) 

The present procedure requires a number of ancillary definitions, which follow: 

Let the service categories be denoted by k= 1..N, where k also denotes the cost of service. 

Let server. maxMinFlowRate[k- 1 ] be the top of the stratum for service category k. Note that 
server.rnaxMnFlowRate [N-l] = server.maxFlowRate. 

Let S K be the set of active client indices with a service category equal to or less than k. Note 
that SI is contained in S2, S2 is contained in S3, and so forth, and that Sk - S^vecz^ 

Let swingCapacity(k) denote available swing capacity for service category k By construction, 

(19) swingCapachy(k) » minimum of : 

(server. maxMnFlowRate [k-1] - Z Iea (cfient.Iookup(i) .sessioaminFlowRate)), 
(server.maxFlowRate - £ j 8 s«tiwCBmt8 (cUem.lookurXi). sessionminFlowRate))) 

Now, referring to figurel3: 

This method is used for CAC when multiple rate tariffs are in effect, and there is a desire to 
maximize economic returns to the service provider while offering acceptable service to all. 

All waiting clients are scanned in FIFO sequence. The actions taken in Steps 1320 and 1360 
are identical to those described in connection with earlier CAC flowcharts. 

Step 1340 evaluates a predicate expression that tests whether the required bandwidth can be 
accommodated without exceeding the lesser of 1) swing capacity available to the client's 
category of service, and 2) total available swing across all categories of service. The latter 
factor could be determinative if all available bandwidth were allocated to high paying 
customers, leaving lower paying ones such as the proposed client unable to draw from their 
unfilled quota. 

Let us suppose that candidate client id belongs to rate category k. 
We define the swing capacity available in rate category k as: 
swingCapacity(&) = least of : 
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(server. maxMnFlo wRatefk- 1 ] - £ llvS k (client Jookup(i).session.minimumFlowRate)) 
and 

(server.maxFlowRate - X i 9 sadfoCBeats (chemJookup0).session.miriimnn^ 

The predicate expression invoked by step 1340 can now be written as follows: 

(requiredjbandwidth <= swingCapadty(A) - server. cac JlowSaf etyMargin) 

Tins algorithm processes queued clients in band sequence; and within every band in FIFO If the 
predicate evaluates to true the client is activated. Otherwise two possible cases are considered: 
1) under the FirstFit embodiment the procedure continues scanning clients to the end of the 
banded queue, activating clients whose requirements can be met; 2) under the FIFO 
embodiment, the procedure ends with the first candidate client whose requirements cannot be 
met. Many other variations on these two embodiments might also be considered. 

4.5.4 Anticipating Scheduled Variations in Network Capacity (Maximal Charge) 
4,5.4.1 Overview 

The procedure applicable to optimization of delivery charges is obtained by blending elements 
of the CAC method depicted in Figure 13 into the method depicted in figure 1 1, which 
applies without change. To understand how this might work it may be useful to visualize a 
version of figure 1 0 stratified along its length in the manner of figure 8. As the m^xim^m flow 
level undergoes a step change so too do the widths of its constituent strata in equal proportioa 

4.5.4.1 Procedure 

As previously mentioned, the method of CAC in section 4.5.3 (figure 1 1) applies to this 
circumstance also, provided we alter the definition of two routines, (17) and (18), upon which 
that procedure relies, yielding (20 ) and (21 ), and adopt the banded queue organization 
outlined in the previous section. 

The server swing capacity at a future time t is computed according to the capacity and worst- 
case client flows at time t. 

(20) swingCapacity(k, t) = minimum of ( 

( server.maxFlowRate(t) *(server . raaxMinFlowRate[k- 1 ]/server. raaxMinFlowRate[N- 1 ]) - 

2 i8Sk&(t_e»ia)>t> (client.lookup(i) > session.mmFlowRate) ), 
(server.maxFlowRate - 

£ i s sutfveaia* & (L«ndCD > o (cHemJookupCi).sessioamiiiFlowRate))) 

Finally, we define a predicate that tests whether a prospective customer will cause swing 
capacity to be exceeded at some time t, as follows: 

(21) boolean cfient_fits(i ,t) { "'V 

k = client.lookupCi).costOfService; * V 

- •■y *:v 

if(cHent.lookupCi).conte^ <= 

swingCapacity(k,t) - serw.cacjaowSafetyMargin) 
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return true; 
else return false; 



A method for call/connection acceptance and flow modulation for network delivery of video/audio 
programming is thus provided. Although several embodiments have been illustrated and described, it will be 
apparent to those skilled in the art that various changes and modifications may be made without departing 
from the spirit of the invention or the scope of the claims. 



nana 71 of 37 



What is claimed is: 



5sa 



A method for optimal multimedia content delivery over networks from server to client comprising 
the steps of: 

Delineating a state variable that represents the data rate to each client; 

Delineating a set of requirements which represent the time-vaiying constraints on the data rate of 
said multimedia content; given by: 

(1 ) The total data rate for aO clients does not exceed the maximum throughput of the server 
or network, whichever is least; 

(2) The data rate from server to client do es not exceed the maximum data rate for the client; 

(3 ) The data rate to the client will never overflow the client buffer 

(4) The server will never underflow 

(6) The data rate from the server will never be less than the client' s minimum data rate, which 
is a non-increasing function of time obtained by dividing the content not yet delivered by 
the remaining play time 



Delineating a cost function which represents the value of a proposed solution 

Performing periodic computi 
^ maximizes said cost function 



Q 

l p Perforating periodic computations to solve said inequalities to obtain the state value that 



\p 2. A method as in claim 1 further comprising: 

i*Q * said requirements further comprise: 

Q The current maximum client data rate is given by the minimum of: 

at 

j<y The stored initial maximum client data rate; 

i i The data rate required to All the remaining client buffer during the current of 

vi • 



said periodic computations; 
The data rate required to complete the delivery of said multimedia content. 
The client data rate never exceeds said current maximum client data rate 

Whereby said current maximum client data rate is periodically recomputed to maintain an optimal 
solution over a give period of time. 



3. A method as in claim 2 further comprising: 

Stud cost function represents maximal throughput and is given by the sum of said client data rates 
for all active clients. 



A method as in claim 2 further comprising: 

Said cost function represents maximal charge and is given by the sum for all active clients of: said 
client data rates times the client 1 s cost of service.. 
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A method as in claim 3 for bandwidth allocation for delivery of multimedia data from server to one 
or more clients over a network, comprising the steps of: 

Determining the maximum flow rate and minima flow rate for each client; 

Determining the flow rate range for each client as given by the difference between said maximum 

flow rate and said minimum flow rate; 
Initializing current flow rate for each client as said minimum flow rate and summing said flow rate 

into total server flow rate; and 
Allocating remaining server bandwidth to remaining clients untill they each saturate or no 

bandwidth remains. 



A method as in claim 5 wherein said step of allocating remaining server bandwidth to remaining 
clients is done fairly by a procedure that comprises the steps of: 

Sorting the list of clients according to said flow rate range; and 

Determining equally-allocated remaining server bandwidth if allocated evenly to all remaining 

unprocessed clients and; 
Determining the range of remaining client bandwidth as given by the difference between said 

maximum flow rate and said minimum flow rate; 
Determining saturation by comparing said equally-allocated remaining server bandwidth and said 

range of remaining client bandwidth, and allocating the lesser of these two amounts to each 

remaining client flow rate; 

Whereby allocating flow to remaining clients based upon the sorted client range flow rates and 
determining allocation of remaining server bandwidth based upon a comparison of saturation 
of server versus saturation of each client maximizes allocation of total bandwidth for maximal 
Sow rate to maximum number of clients. 



A method as in claim 4 for bandwidth allocation for delivery of multimedia data from server to one 
or more clients over a network, comprising the steps of: 

Determining the maximum flow rate and minimum flow rate for each client; 

Detennining the flow rate range for each client as given by the difference between said maximum 

flow rate and said minimum flow rate; 
Sorting the list of clients according to said flow rate range; 

Initializing current flow rate for each client as said minimum flow rate and summing said flow rate 

into total server flow rate; 
Allocating remaining server bandwidth to remaining clients such that lower paying clients receive 

bandwidth only if higher paying ones are saturated. 

A method as in claim 7 wherein said step of allocating remaining server bandwidth to remaining 
clients comprises the steps of: 

For each remaining unprocessed client: 

Detennining equally-allocated remaining server bandwidth if allocated evenly to all remaining 

unprocessed clients and; 
Determining the range of remaining client bandwidth as given by the difference between said 

maximum flow rate and said minimum flow rate; 
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Determining saturation by comparing said equally-allocated remaining server bandwidth and said 
range of remaining client bandwidth, and allocating the lesser of these two amounts to each 
remaining client flow rate; 

Whereby allocating flow to remaining clients based upon the sorted client range flow rates and 
determining allocation of remaining server bandwidth based upon a comparison of saturation 
of server versus saturation of each client maximizes allocation of total bandwidth for maximal 
flow rate to maximum number of clients. 



A method for connection acceptance control for delivery of multimedia data from server to one or 
more clients over a network, comprising the steps of: 

Determining the server swing capacity given by the difference between the total server 
bandwidth and the sum of the minimum flow rate for each client; 

Allocating server bandwidth for each prospective client which will fit without server bandwidth 
saturation, as determined by comparing the average data play rate of each prospective client 
with the remaining bandwidth available to the server. 



A method as in claim 9 wherein said remaining bandwidth available to the server is given by said 
server swing capacity. 



A method as in claim 10 wherein said remaining bandwidth available to the server is given by said 
server swing capacity less a server flow safety margin, thereby allowing server capacity to be 
subsequently lowered by up to the margin without requiring load shedding, and without affecting 
client sessions in process. 



A method as in claim 9 wherein said step of allocating server bandwidth for each prospective client 
which will fit without server bandwidth saturation is further comprised of: 

Allocating server bandwidth to each prospective client sequentially until a prospective client is 
located in which said average data play rate exceeds said sever swing capacity. 

A method as in claim 9 wherein said step of allocating saver bandwidth for each client which will 
fit without server bandwidth saturation is further comprised of: 

Allocating server bandwidth to each prospective client sequentially for each client which can be 
activated without server bandwidth saturation. 



A method for bandwidth allocation for delivery of multimedia data from server to one or more 
clients over a network, comprising the steps of: 

Storing a sequence of data representing scheduled bandwidth changes for the server; 
Determining the maximum flow rate and minimum flow rate for each client at the present time; 
Determining the flow rate range for each client as given by the difference between said mffrfimmi 

flow rate and said minimum flow rate; 
Sorting the list of clients according to said flow rate range; 
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Initializing current flow rate for each client as said minimum flow rate and summing said flow rate 

into total server flow rate; and 
Allocating remaining server bandwidth to remaining clients. 
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Abstract 



A method is disclosed for call and/or connection acceptance control and the optimal delivery of multimedia 
(audio/video) data over networks. This method involves the establishment and monitoring of certain criteria 
which may be used to maximize the number of simultaneous clients without sacrificing quality-of«service 
for already-connected clients. Methods are disclosed for maximizing total throughput as well as ™ff***m)m 
charge models for different levels of service. The disclosed methods solve these optimization problems by 
expanding on linear-program techniques in manners geared towards multimedia content delivery over 
networks and many variations suitable for varying business models are disclosed. 
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